chore: Self healing release - #533

⚠️ No Changeset found

Latest commit: e557ecd

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

I think this adds even more complexity because of a bug in npm that is already fixed

I found the workflow confusing, but sent my 2 cents on review.

What is confusing, could you explain? We have a bunch of automation, but it is not considering situations as the problem that happen this Saturday demonstrated. The SDK release and tags exist, but the publishing of the SDK images don't unless @tuler or whoever has authorisation on docker hub published it manually from that point onwards. That is not a good solution in my opinion. Let me know what in the PR description is confusing

What is confusing, could you explain?

I'm a little away from this code for some time, and I may have lost some context, but I think I'm spoiled by the changesets tool.

Instead of this PR, can't we just bump packages versions that are failing and move on? Would that work?

I think this is more machinery than the problem needs. What happened on Saturday was a one-off: a tooling bug, already fixed in #532, failed the publish step after the tags were pushed. A rare partial failure calls for a simple manual recovery, not checks that run on every push.

This approach adds ongoing cost and risk:

• Every push to a release branch probes the registries and GitHub releases. That's 6 image lookups plus a release query, forever, to cover something that has happened once.
• It fails in the unsafe direction. Any imagetools inspect error, such as a Docker Hub rate limit, a network error or an auth problem, counts as "missing". That rebuilds and re-pushes all 3 images to both registries, overwriting already-released tags with images that aren't byte-identical.
• It doesn't cover the case it's built for. build_sdk and cli_binaries have no status function in their if, so the implicit success() is false whenever release failed, even though artifacts ran with !cancelled(). The jobs get skipped exactly when release fails.
• It hardcodes assumptions about every past tag. The image list and the Foundry pin get applied to whatever tag is being rebuilt. On main, for example, @cartesi/sdk@0.11.1 has no rollups-* images or bake targets, so a branch on that version would trigger a failing rebuild on every push.

A simpler fix: add a manual trigger to sdk.yaml.

on:
    workflow_dispatch:
        inputs:
            ref:
                description: Tag to build, e.g. refs/tags/@cartesi/sdk@0.12.0-alpha.42
                required: true

Keep the ref input and the with: ref: ${{ inputs.ref }} on checkout from this PR. Change the version-tag condition from github.event_name == 'push' to github.event_name != 'pull_request'. Then anyone with Actions access can rebuild a missed release from the tag using the repo's secrets, without needing Docker Hub credentials. That's about 10 lines and leaves release.yaml untouched.

For CLI binaries, a matching workflow_dispatch on a small upload workflow (your cli-binaries.yaml, with the trigger changed) covers the same case.

The recovery becomes: something failed → run the workflow once with the tag. It's explicit, easy to see, and adds nothing to the normal release path.

Generated by Claude Code

can't we just bump packages versions that are failing and move on? Would that work?

That would work. I approved the changes anyway.

What is confusing, could you explain?

I'm a little away from this code for some time, and I may have lost some context, but I think I'm spoiled by the changesets tool.

Instead of this PR, can't we just bump packages versions that are failing and move on? Would that work?

The fix I did Saturday, npm12 fixed + bump changeset cli version made sure what you said to continue to work. Also, I am not ditching the changesets, it will do its work. Is just the after check that I am changing so it is guaranteed to publish missing docker images and binaries (fix to 4 as we are working with only 4) and that we can just replay release and it will do what is suppose to do if we ever get in this situation again (e.g a simple network error would be enough).

@tuler disagrees, so I don’t know, maybe drop this PR and we merge your sdk change and a new release should be good. I made my case and the reasoning behind it, however, it does not look like enough to get some buy in.